Fixes #295 by replicating logic below from Rails abstract_store which propagates the CSRF token from the request environment only during commit_session.

rails/rails@f2c66ce#diff-5207bc67aa19cddd5a4997dec3c69fa4ba541750fbd881c6f7e30b27df9ea9ddR70-R73

rails/rails@f2c66ce#diff-5f81b06a0e3051b576daee16c960b21e715a6cc26d97d020c546d2fa697c9bc6R345-R348

I couldn't really find an alternate approach that seemed better, e.g by re-using the Rails code directly (either Request.commit_csrf_token or AbstractStore.commit_session). This is because in the jruby-rack case, the request object that the store sees appears to be a Rack::Request whereas the Rails abstract_store code expects an ActionDispatch::Request so req.commit_csrf_token is not defined. I couldn't find a way to cleanly access the ActionDIspatch::Request from the Rack::Request either.

How this all works earlier is a bit confusing for me, and the current approach is obviously somewhat coupled to the current Rails 7.1/7.2/8.0 behaviour, but it seemed possibly OK given the otherwise deep integration we are dealing with here? The way they have implemented this in Rails doesn't seem great to me due to the need for AbstractStore to now understand when to invoke a special CSRF hook, so this has created a bit more coupling for us.

Additional minor technical changes

• Changes sessions to inherit from non-deprecated ::Rack::Session::Abstract::Persisted to fix warnings
• Avoid unnecessarily overriding context(env) and align signatures for overridden functions with Rack 2.2.x for easy of understanding (the only supported Rack version for jruby-rack 1.2)
• Prefer newer impl names from ::Persisted rather than legacy ::ID (delete_session rather than destroy_session, write_session rather than set_session)
• corrects appraisal lock files for running on older jruby versions